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REMARKS 

Reconsideration of this application^ respectfully requested in view of the foregoing 
amendment and the following remarks. 

Claims 1-6, 14, 15, 17, 18, 20-22, 30, and 33, and 35-38 have been amended. Claims 7- 
13, 16, 19, 23-29, and 31-32, 34 have been canceled because they are either directed to a non- 
elected invention or no long desired. Claims 1-6, 14, 15, 17, 18, 20-22, 30, and 33, and 35-38 are 
currently pending. 

Applicant's representatives Tiep Nguyen and Mike Morgan, thank the examiner for the 
Office Interview dated April 2 1 , 2005 . 

Rejection of claims 1-6, 13-22, 30. and 33-38 under 35 USC 112, second paragraph, as being 
indefinite 

Claim 1 

In the Final OA, the Examiner took issue with the claimed limitation, "substantially real 
time." The Examiner is respectfully directed to MPEP 2173.05(b), which provides that the term 
"substantially," often used in conjunction with another term to describe a particular characteristic 
of the claimed invention, has been held to be definite by the Court when one of ordinary skill in 
the art would know what was meant. Indeed, one of ordinary skill in the art would understand 
what is meant by the phrase "substantially real time" from a reading of the disclosure. 
Particularly, real-time posting is described and discussed throughout the specification (see, e.g., 
pp. 6, 67, and 68). 
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In the Office Interview, the Examiner suggested the removal of the term "substantially." 

Therefore, in the interest of expediting the prosecution of the application, such term has been 

removed from the claims as it relates to "real-time." Also, as stated in the Office Interview, to 

assist the Examiner with an understanding of the conventional definition for "real-time," attached 

herewith is a definition of such terms from an online encyclopedia relating to information 

technology. For instance, from www.techweb.com , "real time" is defined as follows: 

"A business information system (transaction processing system) that updates databases 
immediately after an order or other transaction has been entered is sometimes called a 
realtime system. This earlier use of the term harks back to when computers were 
becoming fast enough to respond to a query for data within a few seconds. In this context, 
the term "realtime 1 ' might be mentioned to imply any system that provides an immediate 
response." 

Thus, "real-time" processing, as stated in claim 1, should be distinguished from "batch" 
processing, wherein transactions are collected and processed against the master files (master files 
updated) at the end of the day or some other time period instead of processing each transaction as 
soon as the transaction is received. 

Accordingly, it is requested that this rejection be withdrawn because the claims do 
comply with 35 USC 1 12, second paragraph - at least with regard to the claimed limitation, 
"substantially real time." 

The Examiner further took issue with the claimed limitation, "posting of the ready- for- 
posting messages. . .can be interspersed" because it is not a positive recitation that posting 
actually occurs and does not limit the claims. To further clarify the invention and expedite the 
prosecution of the application, claim 1 has been amended to indicate an ability to provide posting 
in real-time and interspersable with the processing of the second type of messages. 
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Accordingly, it is requested that this rejection be withdrawn because the amended claims 
do comply with 35 USC 1 12, second paragraph - at least with regard to the asserted 
indefiniteness due to the original phrase "can be. 55 

The Examiner also took issue with the claimed limitation "scheduling a next time for a 
next activity to be occurred" in claim 1 . Accordingly, claim 1 has been amended for further 
clarification. Support for this claimed limitation can be found in at least pp. 63, 64, 68, 108, and 
109. Therefore, it is respectfully requested that this rejection be withdrawn. 

Claim 3 

Regarding claim 3, it has been amended per the Examiner's suggestion to remove 
indefiniteness due to a typographical error. 

Rejection of claims 1-6. 13-22, 30. and 33-38 under 35 USC 101 as being directed to non- 
statutory subject matter 

This rejection is respectfully traversed because it relies on a non-precedential Board 
decision in Ex parte Bowman, 61 USPQ2d 1669. The Examiner attempted to negate the fact that 
Bowman is non-precedential by stating that such decision is only used for content and reasoning. 
It is respectfully submitted that, indeed, all legal decisions are relied on for their content and 
reasoning, and only if they are precedential. The undersigned representative fails to see how the 
Examiner can rely on Bowman's content and reasoning when it is non-precedential. 
Furthermore, the patent in question in Bowman purposely did not recite any system or structure; 
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whereas, the present invention actually recites a processing system with user interfaces, dbb 
databases, etc. Thus, even the content and reasoning of Bowman is not applicable here. 

However, in the interest of expediting the prosecution of the present invention, the claims 
have been amended, as suggested by the Examiner, to recite "computer-implemented" methods, 
which are supported throughout the original disclosure. Furthermore, also as suggested by the 
Examiner, the claims have been amended to indicate a computerized system performing at least 
some of the claimed limitations. Support for such amendment can be found throughout the 
specification. Therefore, it is respectfully requested that this rejection be withdrawn. 

Rejection of claims 1-6 and 13-22 under 35 USC 103(a) by Kling et al. (5,878,215) in view of 
Northington et al. (6,1 28,602) 

Claim 1 

Claim 1 is directed to a method for posting transactions in real-time and account 
projection to determine financial status of the account. The Examiner asserted that the account 
projection features of the claim - namely, the "retrieving all transactions. . "first 
calculating. . .," "second calculating," and "generating an automatic adjustment. . ." - are shown 
in Northington et al. and that they are inherent to the accounting function of maintaining an 
account balance based on a new receivable amount. This assertion is respectfully traversed for at 
least the following reasons: 

The Examiner's cited sections in Northington et al. merely discuss the periodic generation 
of reports (col. 13, 11. 7-20), the ability to retrieve information from a database (col. 7, 11. 28-44), 
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and the ability to update a database (col. 9, 1. 42 - col. 10, 1. 13), and the updating of credit 
requests (col. 13, 11. 40-59). Thus, Northington et al. do not address the key point of the claimed 
invention - the retrieval of past transactions to process a new transaction. For example, 
Northington et al. in col. 13, 11. 40-59 merely discuss a change in an account credit limit and the 
transmission of such credit-limit change to a database for storage without any further discussion 
on how such credit-limit change can be used for account projection. The Examiner may have 
used such discussion as a basis for asserting that the claimed features are inherent to the 
accounting function of maintaining an account balance based on a new receivable amount. 
However, this inherent accounting function is not the same as the claimed account projection. 

To further distinguish the claimed account projection from Northington et al. and any 
"inherent" accounting function, claim 1 has been further amended to provide a second 
calculation of a second new balance based on both a first new message/transaction and those 
transactions that were already included in the first calculation, wherein the second calculation 
takes into account the effective transaction date of the first new message/transaction relative to 
the other transactions already included in the first calculation. Support for this amendment can 
be found in at least pp. 90-93 of the specification. 

In the Office Interview, the Examiner requested that claim amendments and arguments 
against the cited references of record be accompanied with examples to further explain the 
various claimed methods and features. Therefore, the examples provided below should not be 
construed as the only examples that are applicable to the claimed methods and features. 
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In claim 1, the claimed features stated in parts a), b), and c) are solfexplanatory sglf: 
explanatory in light of the specification. 

The aforementioned amendment to claim 1 takes into consideration of the processing of a 
new transaction that for, whatever reason, has an effective date of some time in the past; for 
example: a) the new transaction is arrived and processed by the system from some place that only 
has paper processing, and it took the new transaction a week to arrive; or b) the new transaction 
is disputed by someone and a credit for the transaction is then given with an effective date of the 
disputed new transaction. Conventional systems and methods generally ignore the fact that such 
new transaction may have an effective date from the past; however, that fact can be important, 
for example, from an accrued interest or fees point of view. For instance, if a credit (i.e., first 
new transaction/message) to an account with an effective date of two weeks ago is processed, the 
account should also be given a credit for the interest that was accruing for those two weeks; 
likewise, if a purchase (i.e., the first new transaction/message) against the account was effective 
two weeks ago, the interest against the account should have accrued from back then. 
Furthermore, a fee may have been generated against the account because the customer was just 
short of the minimum payment. But now a credit with an effective date of two weeks ago means 
that the customer was not short of the minimum payment. 

With the claimed account projection, a first calculation can be done without the early- 
dated first new transaction. Thus, in part dl) of claim 1, for example, all of the ready- for-posting 
transactions relating to an account with effective transaction dates within, e.g., a three-month 
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period from January 2005 through March 2005, are identified. Then, in part d2) of claim 1, for 
example, a first balance for the account is calculated. 

Next, a second calculation is done with the early-dated first new transaction included. 
Thus, in part d3) of claim 1, for example, an early-dated ready-for-posting transaction with an 
effective date within the three-month period, e.g., January 15, 2005, is identified. Then, in part 
d4), a second balance is calculated for the account with the new transaction inserted or 
interleaved, sorted according to its effective date. 

In part d5) of claim 1, when a comparison is done for the two calculations, an automatic 
adjustment can be made to show that an interest is owed to, or due for, the account. Thus, for 
example, the calculations according to the first calculation may have shown a late fee due, 
whereas the newly transaction with an effective date one month in the past causes the second 
calculation to show no late fee due. If the account is already charged the fee on the last 
statement, a credit can then be generated. If the fee was simply generated internally during the 
current statement period but not yet charged to the customer, the fee can then be canceled. 

It is respectfully submitted that Northington et al. do not disclose such account projection 
for its credit-limit change requests or any other transactions. As asserted by the Examiner, at 
best, Northington et al. discuss an adjustment of the account as the mere difference between the 
previous account balance when at maximum credit limit and the value of the new credit limit. 
Thus, there is neither a double calculation of the account nor a comparison between the two 
calculations. 
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Claim 1 is further distinguished from Northington et al. by the following claimed 
limitations, 

"d7) scheduling a next action on the first account by: 

d71) performing in real time the next action on the first account upon 
identifying a second new ready-for-posting transaction that is related to the first 
account, wherein the second new ready-for-posting transaction is identified prior 
to an expiration of a predetermined second time period subsequent to the first 
updating; and 

d72) performing in real time the next action on the first account upon the 
expiration of the predetermined second time period subsequent to the first 
updating, wherein the expiration is reached prior to the second new-ready-for- 
posting transaction being identified; 

d8) repeating the scheduling the next updating of the first account for updates of the first 

account subsequent to the second updating." 

The above limitations describe a process of the present disclosure wherein as 
stated in d71) of claim 1, for example, an account is brought up-to-date when there is an activity 
for that account. That activity may be a purchase or credit transaction (i.e., "the second new 
ready-to-posting transaction") that comes in for an account, or it may be a customer or agent 
accessing an account through the customer service interface. Thus, the account will be up-to- 
date in real-time with respect to such purchase or credit, and such transaction triggers the account 
update with other transactions that accrue, such as interest or generated fees (e.g., late payment 
fees) since the last account update. However, as stated in d72) of claim 1, for example, if no 
such transaction is retrieved prior to a set time period (i.e., " the predetermined second time 
period") account updating will proceed anyway. 

In another example, consider the system processing a purchase example for an account on 
May 1. To save resources, we do not want the system to have to touch that account again until 
absolutely necessary (unlike traditional batch account processing, which touches all active 
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account every night). So we generate a next activity date for the next known activity where we 
will have to touch the account - in this example, it will be to generate a statement on May 10. If 
no new transactions or queries occur for that account before May 10, we will not touch the 
account until that statement generation, and we will have saved resources. If a query or 
transaction occurs, say on May 5, we will process the transaction and again set the next activity 
date to May 10 for the statement generation. 

Northington et al., col. 14, 11. 29-67, as previously cited by the Examiner merely discusses 
the ability of a user to schedule a transaction in the future, namely, "a given date X." In contrast, 
the claimed invention provides an account update to occur both when there is no additional 
transaction and when an additional transaction triggers it in the future, and the process is 
repeated; for example, when an additional transaction triggers it, the next action for the account 
will happen a predetermined second time period after the triggered additional transaction. 

Claims 33-34 

Claim 34 has been canceled, and its claimed limitations have been incorporated into 
claim 33. It is respectfully submitted that a "credit limit" is not a "balance" in accordance 
conventional definition in the art. As understood in the art, a "balance" refers to a value 
representing, for example, the total fees, total interest owed, total money owed, total money owed 
from a set of accounts year-to-date, etc. In other words, a "balance" is a calculated sum of some 
set of numbers, and, in particular, it is NOT a set parameter. Therefore, while an account may 
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have a credit limit amount, there is no such thing as a "credit limit balance" - only an "available 
credit amount", as calculated below: 

Credit Limit = account balance + available credit. 
Furthermore, there is no mention of a third balance as stated in claim 34, which is now 
incorporated into claim 33. 

Claims 35 and 36 

These claims describe the balance aging process with special data types and relationships 
between multiple balances. This balance aging process is different from the balance contribution 
process in the now amended claim 33. For instance, for an account having a Balance A, Balance 
B 5 and Balance C, at some point in time, the claimed invention provides for the moving of an 
existing value of Balance A to Balance B, and the existing value of Balance B to Balance C. 
Support for these claimed features can be found in at least pp. 1 1 1-1 15 of the specification. 
Claims 35 and 36 have been amended to further ensure the claimed balance aging process is clear 
and distinguishable from the references of record, whereby the balancing aging process is 
performed based on a setting up an "aging chain of balances". It is respectfully submitted that 
such claimed set-up of an aging chain of balances and the resulting balancing aging process are 
neither disclosed nor made obvious by the references of record. Indeed, the Examiner provided 
no explanation as to why these claims are rejected, except that they are rejected for the same 
reasons as provided for claims 33 and 34, which are directed to different limitations. 
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As a further elaboration, according to the claimed invention, the concept of an aging 
chain is created as a basic data structure. Conventionally, when the business decides it needs to 
change the aging or add aging to a new field, a programmer must code by hand how that aging 
will work. With the claimed aging chain, someone may simply tell the system, for example, that 
four Data Elements called Current-Fees, Fees-Last- Week, Fees-Two-Weeks-Ago, and Fees- 
Three- Weeks-Ago form a week-based aging chain, in that order. The custom programming only 
needs to worry about updating Current-Fees, not about aging. Because the system understands 
aging chains, every Sunday morning after midnight, it will move the value from Fees-Two- 
Weeks-Ago to Fees-Three- Weeks- Ago, then move Fees-Last- Week to Fees-Two-Weeks-Ago, 
and then Current-Fees to Fees-Last- Week. Lastly, it will set Current-Fees to 0 or to a different 
specified default value. It will do this for all specified aging chains, freeing the programmer to 
worry only about updating the core value and only worry about aging to the extent of specifying 
the needed chains. 

Claims 37 and 38 

The Examiner indicated that it would have been obvious to refer to historical activity 
within the account period; yet, the Examiner made no mention of the claimed "periodic account" 
and where is such account disclosed or made obvious in the references of record. As stated in the 
specification, e.g., in pp. 1 18-1 19, a periodic account is defined as an account in which its 
balances are re-initialize after each predetermined period (e.g., re-initialization is done every day 
for a periodic account having a period of one day). Furthermore, claim 38 provides for different 
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time periods for different periodic accounts. It is respectfully submitted that there is no mention 
of the claimed periodic accounts or associated different time periods in the references of record. 

To further elaborate, consider examples where one daily and one monthly periodic 
account are defined, both of which contain at least the Data Element called Total-Purchases. The 
system will add every purchase amount to the Total-Purchases field in both accounts. The 
periodic part comes into play when the specified period is reached. With the daily account, at 
midnight, the system would automatically take a snapshot of the daily periodic account's fields 
and store them away for safekeeping. It would then reinitialize each Data Element to its 
specified default value. For Total-Purchases, it would reset it to 0. The monthly account would 
continue accumulating the Total-Purchases value until the end of the month. At that point, the 
system would take a snapshot of the monthly periodic account for safekeeping and reset its 
values. So the periodic accounts provide a built-in mechanism for accumulating desired values 
and keeping snapshots of them according to a specified period. 

Conclusion 

For at least all of the above reasons, it is respectfully submitted that the present invention 
is neither disclosed nor suggested by the references of record, and the claims now pending 
patentably distinguish the present invention from the references of record. Accordingly, 
reconsideration and withdrawal of the outstanding rejections and an issuance of a Notice of 
Allowance are earnestly solicited upon the filing of an RCE. 
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Respectfully submitted, 



Date: 



KILPATRICK STOCKTON LLP 
607 14 th Street, N.W. 
Suite 900 

Washington, DC 20005 
Phone: 202-508-5800 
Fax; 202-508-5858 

BOH/THN/48535.268245 



By: 




Tiep H. Nguyen 
Registration No. '44,465 
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